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We present the Linux package configuration tool aspcud based on Answer Set Programming. In 
particular, we detail aspcud's preprocessor turning a CUDF specification into a set of logical facts. 

1 Introduction 

Answer Set Programming (ASP; ||3l) owes its increasing popularity as a tool for Knowledge Represen- 
tation and Reasoning (KRR; fiTTI ') to its attractive combination of a rich yet simple modeling language 
with high-performance solving capacities. The basic idea of ASP is to represent a given computational 
problem by a logic program whose answer sets correspond to solutions, and then use an ASP solver for 
finding answer sets of the program. This approach is closely related to the one pursued in propositional 
Satisfiability Testing (SAT; |4|), where a given problem is encoded as a propositional theory such that 
models represent solutions to the problem. Even though, syntactically, ASP programs resemble Prolog 
programs, they are treated by rather different computational mechanisms, based on advanced Boolean 
Constraint Satisfaction technology. Albeit SAT and ASP both focus on the generation of propositional 
models, they differ regarding the semantics of negation, which is classical in SAT and by default in ASP. 
The built-in completion of "negative knowledge" admits compact problem specifications in ASP, using 
rules to describe the formation of solution candidates and integrity constraints to deny unintended ones. 

Pioneering work on Linux package configuration was done by Tommi Syrjanen in fl^, using ASP 
for representing and solving configuration problems for the Debian GNU/Linux system. Following this 
tradition, we developed the ASP-based Linux package configuration tool aspcud, leveraging modern ASP 
technology for solving package configuration problems posed in the context of the mancoosi project |[T3]| . 
As shown in Figure [T] aspcud comprises four components, all of which are freely available at [2] (and 
via [15,1 ). A given specification (in CUDF; [17]) is first preprocessed and mapped to a set of (logical) 
facts; this step is explained in Section[2] As detailed in Section|3j the facts are then combined with one 
or more (first-order) ASP encodings of the package configuration problem and jointly passed to the ASP 
grounder gringo fT|. (Our ASP encodings, which are also presented in a companion paper [6] detailing 
multi-criteria optimization capacities of the ASP solver clasp [SJ and evaluating them on package con- 
figuration problems, are provided here for completeness.) The instantiation of first-order variables upon 
grounding results in a propositional logic program whose answer sets, representing problem solutions, 
are in turn computed by clasp. The impact of preprocessing on residual problem size as well as solving 
efficiency is empirically assessed in Section |4] (We do not vary solving strategies here; an experimental 
comparison between different solving strategies can be found in HIIH.) Finally, in Section|5} we discuss 
and compare our methodology with related package configuration approaches. 
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Figure 1: Workflow of aspcud. 



2 Preprocessing 

Our package configuration tool aspcud accepts input in Common Upgradability Description Format 
(CUDF), developed in the mancoosi project to specify interdependencies of packages belonging to large 
software distributions. The task of a package manager is to find admissible installations satisfying partic- 
ular user requests, typically also taking into account soft criteria, such as minimal change of an existing 
installation. While CUDF admits arithmetic expressions, package formulae, and virtual packages (see 
below), aspcud's preprocessor generates a flat representation of package interdependencies, so that they 
can be conveniently handled by the ASP components of aspcud taking over afterwards. Below, we give 
a quick overview of CUDF and optimization criteria, and then describe the generation of ASP facts. 

2.1 Common Upgradability Description Format (CUDF) 

The general schema of a "CUDF document" (with an optional preamble; cf. [17]) is as follows: 

preamble 

package: namei package: namei ... package: nameH 

version: versi version: vers2 ... version: vers„ request: 

descrlptioni descriptlon2 . . . descriptionn description 

The pairs (name/, vers/) for 1 < / < n identify installable packages along with positive integer versions; 
they must be mutually distinct, that is, name/ ^ name,,, or vers/ 7^ vers™ must hold for all 1 < 
I < m < n. Then, the universe described by a CUDF document is the set = {(namei, versi), 
(name2, versi), . • • , (name,,, vers„)} of pairs identifying installable versioned packages. 

Each pair (name/, vers/) can be accompanied with (optional) properties provided in 
descrlptioni. In the most general form, a statement in descrlptioni looks as follows: 

property: Pi^ \ Pii \ ■ ■ ■ \ Pk^ , I ^"2, I • • • I , Pi„, \ P2^ \ ■ ■ ■ \ Pk„, 

In such a statement, property G {conflicts, depends, reconmends, provides} determines a kind 
of package interdependency, ' | ' and ', ' stand for disjunction and conjunction, respectively, and pj. for 
1 < / < m, 1 < ji < kj is an expression of the form 'name [op n]\m which op G {=, ! =,<,<=,>,>=} 
denotes an (optional) arithmetic operation along with a positive integer n. Moreover, if 'installed: 
true' is provided in descrlptioni for \ < I <n, it means that package name/ in version vers/ 
belongs to an existing installation, and we denote the set of all such pairs (name/, vers/) by 0". 

For a property G {install, remove, upgrade} in the description below the keyword 
'request : ', for uniformity, we assume the same syntax as with package property statements con- 
sidered beforej^ The requested properties describe goals that must be satisfied by a. follow-up installa- 

'The specification of CUDF 1171 is more restrictive by not allowing for disjunction in package formulae associated with 
property £ {conflicts, provides, install, remove, upgrade}. Moreover, note that CUDF additionally admits keep as 
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Figure 2: CUDF document specifying the (non-empty) interdependencies rflr^efs(inst, 3, conf licts) = 

[{(conf, l), (conf , 2)}], Targets{inst, 2, depends) = [{(dep, l)}], Targets{inst, 1, depends) = [{(dep,n) | 
n £ N}], rargefi(f eat, 1, provides) = [{(conf , 3)}], rargefi(dep, 3, conf licts) — [{(dep,n) | n € N}], 
rargefi(dep, 3, recommends) — [{(recomm, n) | n £ N}], 7flrgefi(dep, 2, conflicts) = [{(dep,l)}], 
rflrgefi(recomm, 1, conf licts) = [{(option, n) | n G N}], and 7argef5(option, 1, depends) = 
[{(avail, n) | n € N}]; (non-empty) request targets consist of rflrgefi(install) = [{(inst,n) | n E N}] 
and Targefi (upgrade) = [{(conf ,n) | n G N,n > 1}]. 

tion 3^, where certain versioned packages might have to be installed, removed, or upgraded, respectively. 
In order to abstract from arithmetic expressions admitted in CUDF, for 'name [ op j2 ] ' , we define: 

{(name,«) | n G N+ such that {n op n) holds} if op n is specified 
{(name,?i) | n G N+} if op n is omitted 

We extend the notion of targets to package formulae associated with some property G {conflicts, 
depends, recommends, provides, install, remove, upgrade} by defining the following multiset]^ 

Targets (property) = [targets{pi.) U targets{p2^ U • • • U targets{pkj) \ l <i <m\ 

Moreover, let Targets{namei,^eTSi, property) be Targets{property) for (name/, vers/) G 
and property ^ {conf licts, depends, recommends, provides}, where either a unique package 
formula is provided for property in descriptioni, or Targets (property) = if property 
is not specified in descriptioni. Likewise, we let Targets(property) = for property G 
{install, remove, upgrade} if no corresponding statement is provided in the description below 
'request : ', while the package formula defining property must be unique otherwise. 

As an example, consider the CUDF document shown in Figure |2] The existing installation, 
marked via 'installed: true', is = {(conf , 1), (dep, 1), (avail, 1)}. The universe, including 
all versioned packages, is'^ = ^U{(inst,3),(inst,2),(inst,l),(conf,2),(feat,l), (dep, 3), 
(dep, 2), (recomm, l), (option, l)}. The CUDF document further specifies the (non-empty) multi- 
sets of targets of package interdependencies and requests, respectively, provided in the caption of Fig- 
ure |2| their particular meanings are described below in the context of ASP fact generation. 

property in descriptioni for 1 < / < n, which we omitted here because it is straightforward to map keep to install. 
^Multisets are needed to reflect optimization criteria deahng with (un)satisfied recommendations, below collected in R^^. 



targets(name [op n] 
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2.2 Optimization Criteria 

The preprocessor of aspcud takes optimization criteria evaluated in competitions by mancoosi |[T3]| into 
account. Given a universe , an existing installation d', and a follow-up installation such criteria 
rely on the minimization or maximization of the following sets: 

Nf = {name I (name,vers) G ^,{(name,?i) I « G N}n^ = 0} 

Df = {name I (name,vers) G ^,{(name,?i) I « G N}n=^ =0} 

cf = {name I (name, vers) G (^\^)U(^\^)} 

= {name I (name, vers) G (name, max{« I (name, «) G "^l) ^ 

= {(name, vers,/) | (name, vers) G 3^ ,Rir\Provide{0^) =0, 

rargef5(name, vers, recommends) = . . . . . . ,Rm\} 

Here, Nf is the collection of packages name such that some version vers belongs to while 0" 
contains no pair (name,«); that is, package name is new in the follow-up installation ,"3^. Similarly, 
Df and Cf collect packages name that are deleted or changed, respectively, where change means that 
some version vers of name is new or deleted in the transition from to 3^. The sets and R^ 
investigate the follow-up installation ^ relative to the universe ^ . A package name belongs to 
if, for each pair (name, vers) in ,0^, there is some (name,?i) in ^ such that vers < n; that is, 
the latest version of name is missing in Finally, a triple (name, vers,/) in Rl^ points to a dis- 
junction 'p\. I P2, I • • • I Pk '^he recommends statement associated with (name, vers) such that 1^ 
neither contains nor provides any element of targets{pi.) U targets{p2j) U • • • U targets (pi^.). In fact, by 
Provide{^) = \J(^n^^^,jQ^^-j^_c^Provide{name,vers) and Provide {name, vers) = {(name,vers)}U 
(U/'e7argeri(name,vers,provides)^)' ^c refer to the union of ^ and the targets of its packages' provides 
statements. This allows us to abstract from "virtual packages" that may not be installable themselves, but 
can be provided by other packages. Note that installable and virtual packages are not necessarily disjoint; 
e.g., the CUDF document in Figure [2] specifies version 1 and 2 of conf as installable, while version 3 
is provided by (f eat, l). In the following, we indicate the objective of maximizing or minimizing the 
cardinality of any of the sets Of^^ defined above by writing +Of^^ or —Of^^, respectively. 

2.3 Generation of ASP Facts 

We are now ready to specify the algorithm applied by aspcud's preprocessor to compute the transitive 
closure of versioned packages that may belong to a follow-up installation The general idea is to 
include versioned packages by need, that is, if they are among the targets of some install or upgrade 
request, a depends statement, or may otherwise serve some user-specified objective. (E.g., +Nf de- 
scribes the objective of installing as many new packages as possible, so that all pairs (name, vers) 
in such that name does not occur in would be added to '^.) Given a universe an existing 
installation ^, and a set O C {+Nf , -Nf , +Df , -Df , +Cf , -Cf , +Uf , -Uf , +Rf , -Rf } of 
objectives, the transitive closure 'rf is computed via Algorithm[T] 

In Line 1 of Algorithm [TJ "negative" requests given by remove and also upgrade are evaluated; 
packages that must not be installed are collected in Out to exclude their addition to ^ in the sequel. 
While exclusions due to remove statements are straightforward (any package fulfilling some remove 
target must not be installed), the issue becomes more involved with upgrade. On the one hand, any 
element of Targef* (upgrade) resembles an install request because it must be served by some package 
(directly or via a provided virtual package) in a follow-up installation J^. On the other hand, there are 
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1 Out ^ {(name, vers) € | Z) € 7ar^efs(remove),Dnf rov/t/e(name, vers) 7^ 0} 

U {(name, vers) G'^ \ U £ Targets{upgTa.de) , [name' ,m) G U, 

(name',n) G Prov/c/e(name, vers), (name',n') G Provide{ff)^n < n'} 
U {(name, vers) G | t/ G Targets{wpgTa.d.e), 

1 < |{(name',«) G Prov/iie(name, vers) | (name',m) G 
U {(name, vers) G | t/ G rargefi(upgrade),f/ nf rov'it/e(name, vers) =0, 

{name' | (name',m) G t/}n{name' | (name',n) G Pre'v/c/e(name, vers)} 7^0} 

2 if {/ G rflr^ef.s(install) U Targets(u.pgra.de) \ inProvide{'^ \ Out) = 0} 7^ then return 

3 {(name, vers) G '^\Out \ /G 7argefi(install)urflrgefi(upgrade),/nProv/c/e(name, vers) 7^0} 

4 if +Nf G O then -^^"^U {(name, vers) G '^\OMf | {n | (name,n) G ^} = 0} 

5 if-Df G O then -^^^"^U {(name, vers) (^'^\Out\{n \ (name,n) G 1^} 7^ 0} 

6 if +Cf G O then '^-^'^U {(name, vers) G ^\OMr | (name, vers) ^ ^} 

7 if-Cf G O then "^^^-^U {(name, vers) £'^/\Out \ (name, vers) G 0} 

8 if +U;f G O then ^ 'g'U {(name, vers) G '^XOut \ vers < max{n | (name,n) G '^}} 

9 if G O then ^ "^U {(name, vers) G \ Owf | rflrgef.s(name, vers, recommends) 7^ 0} 

10 repeat 

11 Add ^ {(name, vers) G \ (OMf U*^) | (name', vers') G 

Z) G 7flrgefs(name', vers', depends), DnProv;c/e(name, vers) 7^0} 

12 if -R^ G O then A<i<i <-Ad<iU{ (name, vers) G \ (Om? U^) | (name', vers') G 

G rflrger.s(name', vers', recommends), /?nProv/t/e(name, vers) 7^0} 

13 if-Uf G OthenAJd^Ac/c/U{(name,max{n I (name,n) G '^^j) G \ (Cm? U<^) | 

(name, vers) G "i^} 

14 "^^"^UAJJ 

15 until Add = 

16 return 'tf 

Algorithm 1: Compute transitive closure 'tf wrt. universe existing installation ^, and objectives O. 

three additional requirements, which can make the installation of particular packages prohibitive. First, 
the version number of packages subject to upgrade must in a follow-up installation not be smaller 
than in the existing installation ^ (if some version is provided by Second, exactly one version must 
be available in so that packages providing several versions at once cannot belong to J!^. Third, the 
install request implied by an upgrade target along with the unique version requirement prohibit the 
installation of packages providing only non-matching versions. These three conditions are taken into 
account to reflect upgrade requests in Out^ (For the CUDF document in Figure |2j (conf,2) and 
(feat,l) can fulfill the target of the upgrade request 'conf > 1', while (conf,l) is excluded in 
view of its non-matching version.) Given the set Out of packages that must not belong to a follow-up 
installation the test in Line 2 of Algorithm [T] identifies cases in which install or upgrade targets 
remain unsatisfiable, regardless of further preprocessing, so that can be immediately returned. 

Provided that the test in Line 2 failed, packages not in Out that may serve some install or upgrade 
target are used to initialize the transitive closure 'to in Line 3. In Line 4-9, ^ is further extended in view of 
the objectives in O. As already mentioned, it might be desirable to install any version of a package name 
not occurring in the existing installation 0" if belongs to O, describing the objective of installing 
as many new packages as possible; if so, is extended accordingly in Line 4. Note that the objectives 

■'The CUDF specification ^11] disallows disjunction in upgrade requests, and we here generalize upgrade targets to dis- 
junction in an "arbitrary" way. However, in the case without disjunction, the packages included in Out due to an upgrade target 
cannot belong to a follow-up installation £P according to the semantics given in 1171 . 
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of the form +0^^^^ are useless in practice, as they favor follow-up installations ^ that are as different 
from ff, or as suboptimal regarding latest versions or reconmends targets as possible. However, such 
"anti-optimization" would in principle be allowed in the user track of competitions by mancoosi, and 
thus Algorithm [T] includes cases to extend ^ accordingly. The reasonable cases in Line 5 and 7 apply if 
package removals or changes, respectively, are to be minimized, so that it may help to add all (installed) 
versions of packages name occurring in 0' to ^. For instance, if — D^, aiming at the minimization of 
package removals, belongs to O, (conf,2), (dep,3), (dep,2), (dep,l), and (avail, 1) are added 
to ^ in Line 5 for the CUDF document in Figure|2| given that (conf , 1), (dep, 1), and (avail, 1) are 
installed in ff. Note that the installed pair (conf, 1) is not added to 'if, as (conf, 1) belongs to Out. 

After its initialization wrt. requests (Line 3) and objectives (Line 4-9), the transitive closure is 
successively extended in the loop in Line 10-15 of Algorithm[T] To this end, packages (name, vers) 
matching some dependency of elements already in are collected in Line 11, provided that the instal- 
lation of (name, vers) is not excluded by Out. Similarly, packages serving recommends statements of 
elements in are collected in Line 12, but only if the minimization of unsatisfied recommendations is 
requested via the objective — R^. Finally, if packages ought to be installed in their latest versions, as it 
can be specified via — U^, we also collect such latest versions in Line 13. The three cases justifying the 
addition of packages to are applied until saturation, and the obtained fixpoint is returned in Line 16. 
Any package remaining in ^ \ belongs to Out, meaning that it must not be installed, or is irrelevant 
regarding dependencies, requests, and objectives. Hence, packages outside need not be reflected in 
ASP facts (described below), so that both instance and residual problem size can be reduced. For the 
CUDF document in Figure [2j assuming that the objective — is provided in O, 'rf is initialized with 

• (inst, 3), (inst, 2), and (inst, l) in view of the request 'install : inst', 

• (conf , 2) and (feat, 1) in order to serve 'upgrade : conf > 1', and additionally 

• (dep, 3), (dep, 2), (dep, 1), and (avail, 1) due to the objective — Df . 

While tracking the dependencies of these packages does not contribute any further elements to ^, if the 
objective — R;^ is given in O, 'recommends : recomm' associated with (dep, 3) justifies the addition 
of (recomm, l)to^. The packages still outside 'W are (conf, 1), which is excluded due to the provided 
upgrade request, and (option, 1), as it does not support any element of ^ and could thus be included 
only if some of the objectives and would reward new packages or changes, respectively. 

Given the transitive closure of relevant packages, the final step of aspcud's preprocessor is to 
generate a representation of package interdependencies, requests, and objectives in terms of ASP facts. 
Note that, in competitions by mancoosi, objectives are lexicographically ordered by significance; hence, 
we below identify O with a sequence of objectives, written as (#i [0^y^]i, . . . ,#(i[0^^^]„) in increasing 

order of significance, where #,■ G {+,— } and [O^^^], e {N^,D^,C^,U^,R^} for \ <i <n. We 

further associate some ASP constant CQ^^^with each O^^^ (newpackage for = N^, remove 

for Off = D^, change for = C^, uptodate for = U;^, and recommend for O^^ = R^). 
Moreover, for any set P of packages, we write idp to refer to some ASP constant associated with the set P, 
where idp / idp' ifP ^ P'. Then, the facts obtained for a CUDF document (specifying a universe ^ and 
an existing installation iff), a sequence O of objectives, and are collected in 7i as shown in Figure [3] 

In Figure [3j the subset T of tt groups packages fulfilling targets of package interdependencies or 
requests in sets P, and respective facts introduce constants idp referring to P. While facts over the predi- 
cate depends in ([T]l simply link the targets of dependencies to packages that provide them, recommends 
in (|2]) introduces a counter r along with each set P of packages fulfilling a recommendation /?, because 
several elements of the multiset rargef5(name, vers, recommends) = [/?!,...,/?,•,... ,7?^] may share the 
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T = {depends (name, vers, /t//>) . | (name, vers) G "^,0 G 7flrgef>s'(name, vers, depends), (1) 
P = {(name', vers') G | DnProv/c/e(name', vers') ^ 0}} 

U {recommends (name, vers, /ii/>,r) . | (name,vers) G '^,{+Ri^,— R^^jnO 7^ 0, (2) 
rflrgefi(name, vers, recommends) = . ,Rm\, 

f = {(name', vers') G | nProv/iie(name', vers') ^0}, 
'•^ |{1 < m I {(name', vers') G '1^ \ RjnProvide{name' ,^ers') ^ V)} = P}\} 

U {conflict (name, vers, /(i/.) . | (name, vers) G '^,C = UrGrar^;er.s(narae,vers, conflicts) T', (3) 
<d (Z P = {(name', vers') G "if \ {(name, vers)} | CnProv!c/e(name', vers') 7^ 0}} 

U {conflict (name, vers, iWp) . | (name, vers) G (4) 
U G Targets(wpgr&de) M nProv/t/e(name, vers) 7^0, 
C-P = {(name',vers') G "if | C/ nProv/<ie(name', vers') ^ 0, 

U nProv/t/e(name', vers') 7^ U nProv/c/e(name, vers)}} 

U {request (;t//>) . | / G 7argefs(install) U 7ar^ef5(upgrade), (5) 
P = {(name, vers) G | /nProv/t/e(name, vers) 7^ 0}} 

TT = T 

U {satisfies (name, vers, /ii/>) . | (name, vers) G P, (depends (name', vers', /lip) . ) G t} (6) 

U {satisfies (name, vers, /ii/>) . | (name, vers) G P, (7) 

(recommends (name', vers', idp,r) . ) G t} 

U {satisfies (name, vers, ;t//>) . | (name, vers) G P, (conflict (name', vers', /t//>) .)gt}(8) 

U {satisfies (name, vers, /c//>) . | (name, vers) G P, (request (/c/p) . ) G t} (9) 

U {unit (name, vers) . | (name, vers) G '^^} (10) 

U {installed (name, vers) . | (name, vers) G ^} (11) 

U {newestversion (name, max{« | (name,«) G '^}) . | (name, vers) G '^} (12) 

U {criterion (C[o|.^^^]^.,#,/) . | O = (#1 [Of/^]i, . . . ,#„[Of/.^^]„), 1 < / < «} (13) 

Figure 3: ASP facts for a CUDF document, a sequence O of objectives, and a set C '^^ of packages. 



same providers P. Also note that (j2jl contributes facts to T (and 7i) only if for #€{+,—} is among 
the objectives in O. The packages P considered by conflict in ([3]l are obtained by joining all T E 
rargef>y(name, vers, conflicts) in C before collecting their providers in P. Note that (name, vers) 
can by definition (cf. lIlTl ) not be in conflict with itself, even if it fulfills some T G Targets {name, 
vers, conflicts); this situation arises with (dep,3) in Figure |2j where 'conflicts: dep' spec- 
ifies a universal conflict with any version of dep (and packages including dep in their provides 
statements). Additional conflicts may be induced by upgrade requests in view of their unique ver- 
sion requirement, and thus packages providing different elements of some U G Targets{wpgrcLde) are 
marked as conflicting via (|4]l; for instance, the upgrade request 'conf > 1' in Figure [2] is reflected 
by facts 'conflict (conf, 2, i<3?{(feat,i)} ) • ' ^^id 'conflict (feat, 1, i'i{(conf,2)} ) • '» obtained be- 
cause (feat, 1) provides (conf, 3) (as a virtual package). Finally, facts over the predicate request 
in (j5]l group packages P fulfilling install or upgrade requests to express that some element of P 
must be included in a follow-up installation Note that all packages referred to in facts of T, via 
(name, vers) in arguments or belonging to P associated with some constant idp, are elements of the 
transitive closure that is, the package interdependencies and requests specified by T are limited to 'tf. 

The full ASP instance n extracted from a CUDF document is obtained by joining z with further facts. 
The first group of them, given in (|6]l-(j9]) in Figure [5] links packages (name, vers) G P to idp via the 
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unit (inst, 3) . unit (avail, 1 ) . 

conflict (inst, 3, ''^{(conf ,2)} ) • newestversion (avail, 1) . 

unit (inst, 2) . installed (avail, 1) . 
depends ( inst , 2 , /t/{(jjgp i)} ) . 

unit (inst, 1) . request (!t/{(inst,3),(inst,2),(inst,i)} > • 

depends (inst, 1 , ic/{(dep,3).(dep.2),(dep,l)} ) • request (!t/{(conf ,2),(feat,l)} ' • 

newestversion (inst, 3) . 

satisfies (conf , 2, iii{(conf,2)} ) • 
unit (conf, 2) . satisfies (dep, 1, '(^{(dep.i)} ) • 

conflict (conf, 2, /t/{(feat,i)}) • satisfies (dep, 3, /<i{(dep.3),(dep,2),(depA)}) • 

newestversion (conf, 2) . satisfies (dep, 2, /fl'{(dep,3),(dep,2),(dep.i)}) • 

installed (conf, 1) . satisfies (dep, 1, /fl'{(dep.3),(dep,2),(dep,i)}) • 

satisfies (feat, 1, /li/ffeat in) • 
unit (feat, 1). 4- • * ■ o n 

conflict (feat, l,/rf.(_,,u) . satxsf.es (dep, 2, ..'{(,,,.2),(dep,i)}) ■ 

newestversion (feat, 1) satisfies (dep, 1, /.'{(dep.2),(dep,i)}) ■ 

satisfies (mst, 3, id{(inst,3),(inst,2),(inst,l)}) 

unit (dep, 3) . satisfies (inst, 2, /c/{(inst, 3), (inst,2), (inst, i)}) 

conflict (dep, 3,/c/{(dep,2),(dep,i)}) • satisfies (inst, 1 , /t/{(inst,3),(inst,2),(inst,i)} ) 

unit (dep, 2) . satisfies (conf , 2 , 2), (feat, i)} ) • 

conf lict (dep, 2,i(i{(dep,i)}) • satisfies (feat, 1, /<i{(conf,2), (feat, i)}) • 
unit (dep, 1 ) . 

newestversion (dep, 3) . criterion (change, -1 ) . 

installed (dep, 1) . criterion (remove, -2 ) . 

Figure 4: ASP facts 7i obtained for the CUDF document in Figure |2] along with O = (— C^, — Df ). 



predicate satisfies, where idp was introduced in T. The second group of facts in (|T0|)-(|T2]) describes 
the transitive closure 'if, the existing installation ff, and latest versions of packages in via the predicates 
unit, installed, and newestversion. Moreover, facts over the predicate criterion in ( [T3] ) repre- 
sent objectives #i[0^^^^]i occurring in O by an associated constant C[o|"^^ j, and the polarity #,• G {+, — } 
along with the position / in O. E.g., the facts obtained for the CUDF document in Figure |2] and the 
sequence O = (— C^, — D^) of objectives are shown in Figure|4] Note that, in view of unspecified ob- 
jectives regarding recommendations, the respective interdependency of package (dep, 3) is not reflected 
in the facts. However, when — would be added to O, 'recommends (dep, 3, id{(^j~Q^^^ i-)j , 1) . ' 
along with further facts describing (recomm, l) (then also included in would be obtained in n. 



3 Grounding and Solving 

The facts n generated by the preprocessor serve as problem-specific input to the ASP components of 
aspcud, viz., the grounder gringo \1\ and the solver clasp [8|, while general knowledge about package 
configuration problems is provided via encodings. For one, the encoding configuration. Ip in 
Figure [5] specifies admissible follow-up installations for another, optimization . Ip in Figure [6] 
encodes optimization criteria (violations) and corresponding penalties. The encodings are written in the 
first-order input language of gringo, which instantiates the contained variables wrt. n to produce a propo- 
sitional representation suitable for clasp. For space reasons, we confine the presentation to the encodings 
that appeared to be most successful in our preliminary, systematic experiments and are thus used by de- 
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fault in aspcud. However, major strengths of ASP are its first-order input language and the availability 
of grounders to instantiate them; this enables rapid prototyping of alternative problem formulations, and 
we indeed tested several encoding variants before deciding for the ones provided next. 



3.1 Hard Constraints 

Hard requirements for follow-up installations ^ are encoded in configuration . Ip. Here, the rules 
in Line 3-10 are used to abstract from versions if a property applies to all (installable) versions of a 
package. Note that variables are universally quantified, where P stands for the name a package, X for 
a version of P, and D is an identifier, idp, for a set P of packages. In view of this, the auxiliary predi- 
cate pconf lict defined in Line 3 projects out versions X from facts over conflict in 7i. The rule in 
Line 4 then lifts a conflict between some version of P (and packages fulfilling D) to the package name P, 
provided that all (installable) versions X conflict with D; in fact, the condition 'conflict (P, X, D) : 
unit ( P , X ) ' , evaluated wrt. values for P and D given through pconf lict ( P , D ) , refers to the conjunc- 
tion of conflict (P , X, D ) over all instances of X such that unit (P , X) holds. From the facts n in Fig- 
ure|4j conflict ( conf , /<i{(feat,i)} ) ^^'^ conflict (feat , ''i{(conf,2)} ) derived via instances of 
the rules in Line 3 and 4, as conflict (conf, 2 , /<i{(feat,i)} ' ^^'^ conflict ( f eat , 1 , ''^{(conf .2)} ) 
are provided by facts for the only (installable) versions 2 and 1 of conf and feat, respectively. The 
same approach to lift properties to package names P is applied to dependencies and satisfaction relation- 
ships (i.e., membership in a set Preferred to by some idp, given via facts over the predicate satisfies). 

While the rules described so far derive deterministic properties from facts, the "choice" rule in 
Line 14 of configuration. Ip allows for guessing a follow-up installation It describes that, 
for any instance of (P,x) specified by the predicate unit, one may freely choose whether to include 
in (P, X) in an answer set; and a follow-up installation ^ is given by the instances of in (P, X) be- 
longing to an answer set. Hence, the rule in Line 14 opens up the candidate space for which is 
however limited to the transitive closure 'rf (determined via Algorithm [T]) because facts over unit do 
not include packages outside The rule in Line 15 again abstracts from the version X of a package P 
in ^ by projecting out X from in ( P , X ) . Once guessed, it remains to check whether a follow-up 
installation £P is admissible. To this end, the rules in Line 17-24 collect the identifiers idp of target 
sets P of package interdependencies, divided by forbidden and requested target sets in view of con- 
flicts and dependencies, respectively, of packages in and satisfied target sets are determined in 
turn. The actual checks are implemented via the "constraints" in Line 26-28, which deny follow-up 
installations ^ such that the target set of a request (due to some install or upgrade statement in 
the original CUDF document) or a requested package dependency is not satisfied; furthermore, 
a target set forbidden in view of some conflict must not be satisfied. For instance, the require- 
ment expressed by 'request ("i|(inst,3),(inst,2),(inst.i)} ) •' Figure |4 along with the constraint in 
Line 26 deny follow-up installations ^ that do not include any of the packages (inst,3), (inst,2), 
and (inst,l) because satisf ied (/(i|(inst.3).(inst,2),(inst,i)} ' can be derived only if in{inst,«) 
holds for some « G { 1 , 2 , 3}. If so, an instance of the rule in Line 23 as well as the rules in Line 15 and 24 
apply, where the latter relies on satisfies ( inst , jV/{(inst.3).(inst,2),(inst,i)} ' > which abstracts from 
versions of inst. Note that such abstractions and the rules in Line 18, 21, and 24 exploiting them are in 
principle redundant, since analogous rules considering versions in Line 17, 20, and 23 achieve the same 
effect, once a version X of P is determined via in (P, X) . However, our preliminary empirical com- 
parisons between several encoding variants suggested configuration. Ip in Figure [5] as the most 
"efficient" encoding. Finally, an admissible follow-up installation ^ can be read off from instances of 
in (P, X) belonging to an answer set, and so we confine its displayed part accordingly in Line 32. 



Martin Gebser, Roland Kaminski, Torsten Schaub 



21 



1 % analyze package interdependencies 



3 pconf lict (P, D) 

4 conflict (P, D) 

6 pdepends (P , D ) 

7 depends (P, D) 



conflict (P, X, D) 
pconf lict (P, D) 

depends (P, X, D) 
pdepends (P , D ) 



conflict (P, X, D) 



9 psatisf ies (P, D) :- satisf ies (P, X, D) . 

10 satisf ies (P, D) :- psatisf ies (P, D), satisf ies (P, X, D) 

12 % generate follow-up installation 



unit (P, X) 



depends (P, X, D) : unit{P,X) 



unit (P, X) 



14 { in(P,X) 

15 in(P) 



unit (P, X) 
in (P,X) 



17 forbidden (D) 

18 forbidden (D) 

20 requested (D) 

21 requested (D) 

23 satisfied(D) 

24 satisfied (D) 



in(P,X), conf lict (P, X, D) 
in (P) , conflict (P, D) 



in (P,X) , 
in (P) , 



depends (P, X, D) 
depends (P, D) 



in(P,X), satisf ies (P, X, D) 
in (P) , satisfies (P, D) 



26 
27 
28 



request (D), not satisf led (D) . 
requested (D ) , not satisf led (D) . 
forbidden (D) , satisf led (D) . 



30 % project output 
32 #hide. #show in/2 , 



Figure 5: ASP encoding of follow-up installations ^ wrt. facts 7i (configuration . ip). 



3.2 Soft Constraints 

The encoding optimization . Ip in Figure [6] builds on top of facts n and configuration . Ip to 
identify optimization criteria violations and to assign corresponding penalties. While the rule in Line 1 
merely projects out versions X of packages P installed in ^, the rules in Line 5-12 recognize changes, 
additions, and removals of packages P in the transition from to Note that any such violated 
maintenance condition is considered only if associated objectives are specified via facts over the predi- 
cate criterion in 7i; for the facts in Figure|4j the rules in Line 5-8 and 1 1-12 of Figure[6]are applicable, 
given that the sequence O = (— C^, — D^) of objectives is expressed via 'criterion (change, -1 ) . ' 
and 'criterion (remove, -2) . ' Objectives regarding latest versions of packages in and recom- 
mendations are addressed by the rules in Line 13-14 and 15-16, respectively. Note that the latter uses 
a different format, r ( P , X , D ) , to indicate an unserved recommendation D of a package P in version X, 
where D is an identifier of the form idp for a target set P; in addition, the multiplicity of recommenda- 
tion targets served by P is given in R. (Since violations of the other optimization criteria, identified in 
Line 5-14, are counted once per package name P, their corresponding instances of violated ( C , P , 1 ) 
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1 installed (P) 



installed (P, X) . 



3 



identify optimization criteria violations 



5 violated (change, P, 
6 

7 violated (change, P, 
8 

9 violated (newpackage, P, 
10 

11 violated (remove, P, 
12 



1) :- criterion (change, L) , 
not installed (P, X) , in(P,X). 



1) :- criterion (newpackage, L) , 
not installed (P) , in(P). 



1) :- criterion (change, L) , 



1) :- criterion (remove, L) , 



installed (P, X) , not in(P,X). 



installed (P) , not in(P). 



13 violated (uptodate, P, 



1) :- criterion (uptodate, L) , 
newestversion (P, X) , not in(P,X), 



14 

15 violated (recommend, r (P, 
16 



X,D),R) :- cr iter ion ( recommend, L) , 



recommends (P , X, D, R) , in(P,X), 



not satisfied(D) . 



in(P) . 



18 % post optimization criteria 

20 #minimize [ violated (C, P, W) = W @ -L : criterion (C, L) : L < ]. 

21 #maximize [ violated (C, P, W) = W @ L : criterion (C, L) : L > ]. 

Figure 6: ASP encoding of optimization criteria wrt. follow-up installations ^ (opt imi z at i on . Ip). 

use 1 as default weight.) The #minimize and tmaximize statements in Line 20 and 21 associate 
penahies (or rewards) with violations of objectives of the form #,[0^y^^],- in a sequence O, reflected 
in 71 by including 'criterion {cin.ij' i ,#,/) . ' (where Cin:f i € {newpackage, remove, change, 
uptodate, recommend} and #/€{+,—}). Instances of violated (crQ,:>' i ,P,W) in an answer set, 
derived via the rules in Line 5-16, are then penalized (or rewarded) with priority / and weight W. Note 
that summation-based minimization applies (in Line 20) if #,• = — or maximization (in Line 21) if #,■ = +, 
while a later position / in O indicates greater significance than preceding ones. For instance, the sequence 
represented by 'criterion (change, -1) . ' and 'criterion (remove, -2) . ' gives preference to 
the minimization of and then considers the cardinality of for breaking ties. As already men- 
tioned, maximization objectives of the form +0^y^^ (aiming at many differences between and 
outdated packages in or recommendations ignored by respectively) seem of little practical use. 
Since they would still be allowed in the user track of competitions by mancoosi, the tmaximize state- 
ment in Line 21 of Figure [6]is included to handle them. 

The instantiation of configuration. Ip and optimization. Ip wrt. facts n, produced by 
gringo, is passed on to the ASP solver clasp, which searches for (optimal) answer sets of propositional 
logic programs. In the context of Linux package configuration, the major challenge lies in the opti- 
mization of objectives, given that available distributions are large and plenty installations are admissible 
(even when the transitive closure 'rf is used to limit the scope of a follow-up installation In view 
of this, we recently extended clasp by dedicated search strategies and heuristics for effective multi- 
criteria optimization |[51; by default, aspcud configures them by supplying the command line options 
— opt-hierarch=l and — opt-heuristic=l to clasp. (Default clasp options can be overrid- 
den via aspcud switch '-c'.) In a nutshell, these options instruct clasp to optimize multiple objec- 
tives successively in the order of significance by progressively improving objective values of answer 
sets until the problem of finding a better answer set turns out to be unsatisfiable, in which case op- 
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timization proceeds with the next (less significant) criterion. Further search parameters of clasp are, 
by default, set by supplying the command line options — sat-prepro, — heuristic=vsids, 
--solution-recording, --restarts = 128, and --local-restarts. We determined the 
clasp setting utilized by aspcud via systematic experiments (see ||5l|6l for an empirical comparison be- 
tween clasp settings), and the successful participations of aspcud in recent trial-runs of the competition 
by mancoosi [13] were largely owed to the search capacities of aspcud'?, solving component. 

4 Experiments 

The workflow of aspcud includes the steps of preprocessing, grounding, and solving (as well as con- 
verting an answer set representing a follow-up installation back to CUDF). Since clasp settings were 
already evaluated in ID HI, the experiments presented here concentrate on the impact of preprocessing 
on residual problem size and its effect on solving efficiency. To be more precise, we compare problem 
size and search statistics wrt. ASP facts limited to the transitive closure 'lo determined via Algorithm [T] 
against facts describing the whole universe ^ of packages (except for those that must not be installed in 
view of remove and upgrade requests). 

Our experiments consider four benchmark classes, in the following referred to by easy, difficult, 
impossible, and debian-dudf, from the 2010 MISC competition by mancoosi [131 . Furthermore, we 
apply the sequences (— C^, — D^) and (— N^, — R^, — U^, — D^) of objectives (in increasing order of 
significance) used in the tracks called paranoid and trendy. (Arbitrary sequences of objectives can be 
provided as arguments to aspcud, as required in the user track.) Note that, although the instances are the 
same in paranoid and trendy mode, optimization wrt. the latter is usually more difficult in view of more 
criteria. We ran the experiments under MISC conditions, imposing a time limit of 300 seconds, on an 
Intel Xeon E5520 machine, equipped with 2.27GHz processors and 48GB main memory, under Linux. 

Table [T] summarizes experimental results, separately for paranoid and trendy objectives, where the 
first two columns provide the considered benchmark class along with the number n of its instances. The 
entries in the other columns contrast statistics obtained with transitive closure computation (before 7') 
against the ones obtained without it (after 7'). Average problem sizes in terms of number of variables 
and constraints, as reported by clasp, are provided in the third and fourth column. The fifth column gives 
average solving times, with timeouts (in parentheses) taken as 300 seconds. The numbers of choices, 
conflicts, and answer sets (including intermediate ones) reported by clasp are shown in the last three 
columns, here averaging over the instances finished within the time hmit in both preprocessing modes. 

With transitive closure computation enabled, we observe a reduction of both variables and constraints 
by about one order of magnitude (a bit less on the debian-dudf class). This can be explained by the fact 
that typical installations include only a fraction of the available packages. Furthermore, the reductions in 
size are greater wrt. paranoid objectives because they disregard recommendations, which are considered 
in trendy mode. The solving times also reduce by one order of magnitude for paranoid, yet less for the 
more difficult problems solved in trendy mode; however, eight more instances are solved in time with 
transitive closure computation enabled. Interestingly, the numbers of conflicts and answer sets (taken 
only over instances that did not time out) are comparable. This indicates that clasp's optimization ap- 
proach is able to focus on relevant problem parts, even without a priori limitation to the transitive closure. 
Nonetheless, the numbers of choices are much greater (again an order of magnitude) for whole package 
universes, providing a clear indication of the benefits of limiting the scope of follow-up installations. In 
fact, even when unnecessary variables and constraints do not render a problem more difficult, the solving 
time suffers from additional efforts spent on assigning the variables and testing the constraints. 
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n 
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conflicts 
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20 
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22 
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14 


70K/438K 
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35K/51K 
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Table 1: Experiments assessing the impact of preprocessing via Algorithm 1 on aspcud's performance. 



5 Discussion 

We presented the workflow of the ASP-based Linux package configuration tool aspcud. In particular, we 
detailed the preprocessing applied to convert CUDF input to ASP facts suitable for the ASP components 
of aspcud. Related approaches rely on conversions from CUDF to Integer Linear Programming [14J, 
Maximum Satisfiability ||9l, or Pseudo-Boolean Optimization [1]. Although all conversions, including 
ours, closely follow the specification of CUDF llTl and differ primarily in their target formats, there still 
are some differences that deserve attention. Unlike other package configuration tools, aspcud compiles 
CUDF input into ASP facts, while constraints as well as optimization criteria on follow-up installations 
are provided separately via general problem encodings. In fact, aspcud is equipped with several encoding 
variants (selectable via switch '-e'), although we here only detailed the most promising variants accord- 
ing to our empirical investigations. For another, the preprocessors of package configuration tools trace 
indirections in view of arithmetic expressions (over versions), package formulae, and virtual packages 
admitted in CUDF back to the (installable) packages underneath. In our ASP fact format (cf. Figure |3]l, 
we however associate target sets P of package interdependencies with identifiers idp in order to avoid un- 
folding steps upon fact generation. To our knowledge, the preprocessors of other package configuration 
tools perform such unfolding, and it is an interesting (unresolved) question whether structural entities 
of the form idp are rather beneficial or a handicap for search. Regarding modeling in ASP (cf . Figure [5] 
and|6]l, the consequent usage of identifiers idp helped to keep the encodings concise and thus easy to 
maintain and modify. Despite of the different input formats used in ASP and the solving components of 
other package configuration tools, the principal approach of aspcud's preprocessor to limit the scope of 
follow-up installations is independent of back-end solvers; however, an additional "constraint formula- 
tor" would be required for back-ends lacking general-purpose grounders. Concerning subjects to future 
investigation, we speculate that further improvements of problem encodings or the exploration of char- 
acteristic structures in Linux distributions (if any) might boost the performance of package configuration 
tools, in addition to ongoing enhancements of their search engines. 
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